Medición de la calidad del software en el ámbito de la especificación de requisitos (página 2)

Partes: 1, 2

13
2. Medición de especificaciones de requisitos
Algunas características de la ERS dificultan la aplicación de métricas
Diferentes perspectivas de modelado
Es necesario contemplar múltiples notaciones
Evolución
Hay que asegurar la consistencia de los cambios
Transformación
Se requieren medidas de calidad que valoren la trazabilidad
Abstracción
Es difícil medir directamente los atributos de calidad

14
2. Medición de especificaciones de requisitos
Necesidad de Modelos:
Minimizar la complejidad y relatividad inherentes al concepto “calidad del software”
Manejar diferentes perspectivas de modelado
Gestionar la evolución y asegurar la consistencia de los cambios
Crear “Factorías de la experiencia”

3. Medidas basadas en modelos
MPC = ? ci
M1, M2, …,Mn
P = 1 – (ET/ER)

16
3. Medidas basadas en modelos
El éxito en la medición del software está ligado a la obtención, definición y manipulación conjunta de dos modelos:
Modelos empíricos
Contexto empírico del mundo real
Modelos numéricos
Formalización de las medidas del contexto empírico

17
3. Medidas basadas en modelos
(Gp:) Modelo empírico

Medida
(Gp:) Modelo numérico

(Gp:) Resultado empírico

Interpretación
(Gp:) Resultado numérico

Matemáticas/ estadística
Comprensión/ refinamiento

18
3. Medidas basadas en modelos
(Gp:) i
(Gp:) j
(Gp:) k
(Gp:) Modelo
(Gp:) I’
(Gp:) J’
(Gp:) K’
(Gp:) Modelo’
(Gp:) Metamodelo
(Gp:) Meta-metamodelo

Modelo de jerarquía genérico que recoge los aspectos evolutivos y/o de transformación de dos modelos

4. Arquitectura de gestión de calidad de ERS

20
4. Arquitectura de gestión de calidad de ERS
Objetivos:
Gestionar conjuntamente la calidad de diferentes perspectivas de modelado
Formular directamente objetivos de calidad y planes de medida
Proporcionar una base para la automatización de las medidas
Mantener registros de información histórica
Proporcionar soporte para estudios empíricos y construcción de modelos predictivos

21
Modelos en el ámbito de los requisitos
Entorno de
aplicación 2
Entorno de
aplicación 1
Entorno de desarrollo
Meta metamodelo
Lenguaje de modelado
Modelos
Instancias y
escenarios
Ingeniería
de métodos
Modelado
conceptual
Uso
Estructura de referencia ISO IRDS (Information Resource Dictionary System)
4. Arquitectura de gestión de calidad de ERS

22
4. Arquitectura de gestión de calidad de ERS
Basada en la arquitectura IRDS de cuatro capas :
Escenarios e instancias: contiene objetos no instanciables (datos, estados…)
Modelos: representa las clases
Metamodelos: nivel de lenguajes de modelado que define la estructura de las clases
Meta metamodelo: Definición de múltiples lenguajes de modelado

23
4. Arquitectura de gestión de calidad de ERS
(Gp:) UML
(Gp:) Nombre: UML
(Gp:) tipo: gráfico
(Gp:) nº de notaciones: 9

(Gp:) CU-0
(Gp:) Aplicación: contabilidad
(Gp:) Nivel: contextual

Modelo M2
Metamodelo
(Gp:) Casos de uso
(Gp:) Diagrama: casos de uso
(Gp:) Clasificadores: 2

Modelo
Escenario

24
Implementación en un repositorio
Construcción de modelos empíricos de entidades medibles
Recuperación de modelos y datos para realizar medidas
Realización de análisis de datos, presentación e interpretación de resultados
Almacenamiento de modelos y resultados para uso futuro
Automatización de la recolección de datos y aplicación de métricas
4. Arquitectura de gestión de calidad de ERS

25
4. Arquitectura de gestión de calidad de ERS
(Gp:) SGBD
(Gp:) ME
(Gp:) Aplicación 1
(Gp:) Aplicación n
(Gp:) Repositorio
CASE
(Gp:) Repositorio
de gestión de Calidad

5. Conclusiones

27
5. Conclusiones
Construir modelos para:
ayudar a entender qué estamos haciendo
proporcionar una base para definir objetivos
proporcionar una base para la medición
Construir modelos de:
gente, procesos, productos
y estudiar sus interrelaciones

28
5. Conclusiones
Usar modelos para
clasificar el proyecto en curso
distinguir los entornos pertinentes del proyecto
encontrar tipos de proyectos con características y objetivos similares
Los modelos proporcionan un contexto para:
Definición de objetivos
Objetos/experiencias reutilizables
Selección de procesos
Evaluación/comparación
Prediccion

29
5. Conclusiones
El enfoque propuesto proporciona:
Un marco para definir modelos de calidad y objetivos específicos del proyecto
Un mecanismo para evaluar la calidad en las primeras fases del ciclo de vida
Soporte para el registro y uso provechoso de experiencias pasadas
Un medio para gestionar la evolución y la consistencia de los cambios

6. referencias

31
6. Referencias
Albrecht, A.J., “Measuring application development”, Proc. of IBM Applications DevelopmentJoint SHARE/GUIDE Symposium, Monterey, CA, pp 83-92, 1979.
Arthur, J.D. y Stevens, K.T. , “Assessing the adequacy of documentation through document quality indicators”, Proceedings of the IEEE Conference of Software Maintenance, pp. 40-49, 1989.
Basili, V.R. y Rombach, H.D., “The TAME Project: Towards Improvement-Oriented Software Environments”, IEEE Transaction on Software Engineering,14(6), 758-73 1988.
Basili, V.R. y Weiss, D., “A Methodology for Collecting Valid Software Engineering data”, IEEE Transaction on Software Engineering, 10 (6), 728-38 1984.
Binder, R., “Testing Object-Oriented Systems”, American Programmer, 7(4), 22-29, 1994.
Boehm, B.W., Kaspar, J.R. y otros “Characteristics of Software Quality”, TRW Series of Software Technology, 1978.
Boehm, B.W., Clark, B., Horowitz, E. et al., “Cost Models for future life cycle processes: COCOMO 2.0”, Annals of Software Engineering 1(1), pp 1-24, 1995.
Brykczynskki, B., “A survey of software inspection checklist”, ACM Software Engineering Notes, 24(1), pp 82-89, 1999.
Chidamber, S.R. y Kemerer, C.F., “A Metrics Suite for Object-Oriented Design” ,IEEE Transactions of Software Engineering, 20(6), 476-493, 1994.
Churcher, N.I. and Shepperd, M.J., “Towards Conceptual Framework for Object-Oriented Metrics”, ACM Software Engineering Notes, 20 (2), 67-76, 1995.